RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, or video data, over multicast or unicast network services. RTP is designed to be independent of the underlying transport and network layers. Accordingly, RTP does not address congestion control, resource reservation, and does not guarantee quality of service for real-time services. RTP simply provides functionality suited for carrying real-time content, e.g., a timestamp and control mechanisms for synchronizing different streams with timing properties. RTP can be used over either connectionless networks, such as UDP/IP, or connection-oriented networks, such as XTP, ST-II, or ATM (AAL3/4, AAL5).
When RTP is used to transport real-time data over IP networks, the transmission of data between network endpoints (source and destination) is accomplished by establishing RTP stream(s) between the interested parties. An RTP stream can be defined as a one-directional stream of data from a given source to a given destination, characterized by source and destination attributes: source IP address, source UDP port, destination IP address, and destination UDP port. These attributes uniquely identify a particular RTP stream. An RTP session can be made up of one or more RTP streams between two or more participants.
The destination address/port pair may be the same for all participants, as in the case of IP multicast, or may be different for each participant, as in the case of individual unicast network addresses. In a multimedia session, each type of media is carried in a separate RTP stream. The multiple RTP streams can be distinguished by their different UDP port number pairs and/or different multicast addresses.
RTP sessions can be dynamically established through the signaling domain in the context of a running real-time application, such as Voice over IP (VoIP), IPTV, or gaming. Through signaling, the attributes (source and destination IP-addresses, and source and destination UDP-ports) of the RTP streams are exchanged between source and destination endpoints.
For example, in a VoIP application with Session Initiation Protocol (SIP) signaling, RTP stream attributes for an audio stream between a caller and callee can be exchanged through SIP signaling. Specifically, by the caller and callee informing each other of what IP address, and UDP port must be used for the RTP stream.
Therefore, in accordance with the prior art, a third party device trying to detect a given RTP stream in a network, must have visibility into the application level signaling and extract the RTP attributes. Without the RTP attributes, the third party device cannot easily detect RTP packets belonging to a particular RTP stream from amongst other UDP packets in the network. For this reason, typical prior art systems designed to detect RTP streams in networks, parse the signaling domain to identify attributes of the RTP streams on the network, and then, based on the identified attributes search for the RTP streams.
Identifying attributes of RTP sessions by monitoring application signaling can be problematic and inefficient. First, there is a race condition between the discovery of RTP attributes (by monitoring the application signaling), and the start of RTP streams. Typically, RTP streams start immediately after the application signaling occurs. It can be very difficult to ensure that no RTP packets are missed, prior to the detection of RTP streams. Second, in IP networks there can be widespread deployments where signaling, and RTP streams flow on different and separate paths within the network. In such scenarios, visibility into both signaling sessions and media streams (i.e. RTP streams) may not be practical.
In the prior art, there are two methods to overcome those challenges. The first method is to capture all UDP packets in a network, and post-process them by using visibility into the signaling of the application. This method avoids the race condition, but fails to address the scenario in which visibility may be impractical, because the signaling sessions and RTP streams may be on different and separate paths within the network. Furthermore, capturing all UDP packets in a given network typically is impractical, due to CPU processing and storage limitations.
The second method is a simple method that attempts to detect RTP streams based on two constant fields within an RTP header as defined by the RTP specification. An example of such a prior art method is the Ethereal Open Source Project (www.ethereal.org), which uses version number and payload type RTP header fields of a RTP packet for identifying that packet as part of an RTP stream. However, this second method is relatively inaccurate for RTP stream detection, and is marginal at best.
Accordingly, it would be advantageous to provide a system and method that can accurately detect RTP streams. It is an object of the present invention to substantially overcome the above-identified disadvantages and drawbacks of the prior art.